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1. REAL PARTY IN INTEREST 

The real party in interest is Apple Computer, Inc., the assignee of the present 
application, having an address at 1 Infinite Loop, M/S 3-PAT, Cupertino, CA 95014. 

2. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences. 

3. STATUS OF CLAIMS 

Claims 11-15 and 38-42 have been rejected by the Examiner and are being 
appealed before the Board. 

Claims 1-10, 16-37, 44 and 48-50 have already been cancelled. 

Claims 43, 45-47 and 51-58 are canceled by an amendment submitted herewith. 

The claims on appeal (claims 11-15 and 38-42) are reproduced below in the 
Appendix at Section 9 of this Appeal Brief. 

4. STATUS OF AMENDMENTS 

An After Final Amendment dated July 25, 2006 was filed in response to the Final 
Office Action mailed on May 25, 2006. The After Final Amendment amended claims 
11-15 which are being appealed. However, the Examiner has not entered the After Final 
Amendment. Accordingly, Claims Appendix of this Appeal Brief presents the status of 
claims being appealed (11-15 and 38-42) prior to the After Final Amendment and 
therefore includes all the amendments entered by the Examiner. 

5. SUMMARY OF CLAIMED SUBJECT MATTER 
5.7. Independent Claim 11 

The present application relates to techniques for controlling access to records 
stored in a database. As a representative claim, claim 1 1 pertains to a method for 
controlling access to records stored in a database and recites: 

"identifying a password that is associated with one or more users of the database" 

As noted in the specification with reference to Figure 2, at operation 202, an 
access identifier is defined. The access identifier can, for example, be a password 
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associated with a user or a group of users of the database (Specification, page 9, lines 
12-16). 

Claim 11 further recites: 

"defining a calculation expression for said identified password" 

Again, referring to Figure 2 of the application, at operation 210, an expression 
is effectively defined for the identifier with respect to an operation (Specification, 
page 10, lines 1-2). Referring to Figure 7 of the application, an exemplary calculation 
expression 604 is depicted. As shown in Figure 7, the calculation expression 604 
(Billing State = "CA") specifies a formula for controlling edit access to records in a 
specify calculation window 700. As such, the calculation expression defines access 
privileges of one or more users with respect to at least one operation that may be 
requested to be performed by the one or more users on a plurality of records of the 
database (claim 11). 

Claim 11 further recites: 

"wherein said calculation expression is a variable expression defined based on 
at least one field of data used in a plurality of records stored in said database, wherein 
said calculation expression can be evaluated at least partly based on said at least one 
field of data used in said plurality of records, wherein said at least one field of data is a 
variable which may have different values for each of said plurality of records, thereby 
allowing access to each individual record of said plurality of records to be selectively 
controlled based on at least one value of said at least one field of data stored for each of 
said plurality of records of said database" (claim 11). 

As noted on page 14 of the specification, a calculation expression can be 
defined based on various fields of records stored in a database, as well as other 
variables, for example, the state information of the database (e.g., date, time, number 
of records, etc.). Accordingly, access can be defined based on a calculation 
expression (Specification, page 10, lines 2-6). More particularly, a calculation 
expression can be evaluated to determine whether access should be granted with 
respect to an operation that is requested to be performed on a record stored in the 
database. Accordingly, a user or group of users associated with a password can be 
granted or denied access to the records of the database based on a calculation 
expression that can be defined with respect to an operation that can be performed on a 
record (Specification, page 14, lines 13-18). To illustrate, Figure 8 of the application 
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depicts an exemplary file ACCOUNTS that includes records "ACC001", "ACC002", 
"ACC003" and "ACC004" displayed in a window 800. For example, these records 
can represent billing addresses of customers. As noted in the specification, a field 
"State" can indicate the state portion of the billing address for the customer. 
Considering the exemplary calculation expression 604 of Figure 7, access to a record 
with respect to an operation would be granted only when the field "State" (Billing 
State) of that record is equal to "CA." Accordingly, using the calculation expression 
604, access to records shown in Figure 8 with respect to editing privileges, for 
example, would be limited to editing records "ACC001", "ACC002", and "ACC004" 
(Specification, page 14, lines 18-29). 

Claim 1 1 additionally recites: 

"receiving a request to perform said at least one operation on said plurality of 
records of said database, said request being identified as a request made by said one or 
more users associated with said password; and 

evaluating said calculation expression for each of said plurality of records, 
based on said at least one field of data, when said request has been received, wherein 
said evaluating comprises: (a) determining at least one value for said at least one field 
of data stored for a first record of said plurality of records, (b) using said at least one 
value as input to said calculation expression to evaluate said calculation expression for 
said first record, and (c) determining a first result for said calculation expression based 
on said evaluation of said calculation expression for said first record, wherein said first 
result effectively indicates whether to grant access to said first record." 

Referring to Figure 9 of the application, at operation 902, a request to access a 
record can be received. Further, an expression can be evaluated (906) to determine 
whether to allow access to the record based on the evaluation performed for the 
record. Referring back to the example depicted in Figure 8 of the application, it is 
clear that when the calculation expression 604 depicted in Figure 6 (Billing State = 
"CA") is evaluated, for example, for the first record, the value of the sixth (6 th ) field 
(Billing State) is initially determined. As such, this determining (a) determines that 
the sixth (6 th ) field (Billing State) stores data representing "CA." Subsequently, the 
data ("CA") obtained from the sixth (6 th ) field (Billing State) of the first record can be 
used as input to the calculation expression 604 (Billing State = "CA"). In other 
words, actual data ("CA") is used as input for the variable field "Billing State" 
expressed in the calculation expression 604 in order to evaluate (b) the calculation 
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expression. Finally, based on the evaluation (b) a first result can be determined (c) to 
effectively indicate whether to grant access to the first record. In this example, the 
evaluating (b) would result in an indication to grant access since the data of the sixth 
(6 th ) field (Billing State) is equal to the value specified in the calculation expression 
604 ("CA"). However, as noted in the specification, the same user would not be 
granted editing privileges to a record that does not store the value ("CA") in its sixth 
(6 th ) field (Billing State). See for example, the third (3 rd ) record shown in Figure 8 of 
the present application. In this way, a calculation expression can be evaluated for 
multiple records to determine whether to grant or deny access to each record 
(Specification, page 14, lines 27-31). 

To summarize, Figure A of Appendix A provided in Section 12 of the Appeal 
Brief depicts a database 10 that includes a plurality of tables (or files) 12 where a 
particular table (or file) 12a is represented with a plurality of records R (Ri-R n ). 
Referring to Figure A of Appendix A, a particular record Rl is represented with a 
plurality of fields Fi 5 F 2 , F 3 , F 4 andF 5 , respectively storing data Dn 5 Di 2 , Di 3; D i4 and 
D i5 . Database users Ul and U2 are also depicted in Figure A of Appendix A where 
passwords PI and P2 are respectively associated with the database users Ul and U2. 
Moreover, calculation expressions C 1 and C2 are defined respectively for passwords 
PI and P2 associated with database users Ul and U2. Similar to the example noted 
above, the calculation expression CI is expressed as: 



(F2 = 'CA'). 



The calculation expression C 1 defines access for the first password P 1 and 
thereby the first database user Ul . Moreover, Calculation expression CI can be 
evaluated for each of the individual records (Ri_ R n ). This means that in order to 
evaluate the calculation expression CI (F2 = 'CA') for the first record (Ri), the data 
in the corresponding field (F2) is obtained and subsequently used to evaluate the 
calculation expression CI in order to determine whether the first database user Ul 
should be granted access to the first record. Thus, actual data in the second field (F2) 
of the first record (Ri), namely, D12 is used to determine whether access to the first 
record Rl should be granted. Next, the second field (F2) of the second record (R2), 
namely D22, can be used to evaluate the calculation expression CI (F2 = 'CA') for the 
second record, and so on. 
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It should be noted that more complex calculation expressions can be defined. 
To provide an example, Figure A of Appendix A depicts a calculation expression C2 
expressed as (Fl + F2) >= 'Constant Value K' which can also be evaluated 



individually for each one of the records Ri_ R n . To evaluate this expression for the 
first record (Ri), data actually stored in the first and second fields (Fl and F2) are 
obtained and subsequently added together to determine their sum. This means the 
actual data values Dn and D12 are obtained and then added together to determine 
whether the sum is greater or equal to the 'Constant Value K\ This, for example, 
would allow access to all the records where the billing amount for two given years 
(provided in two fields of a record) is equal or exceeds a particular amount. 

It is apparent that more complex calculation expressions can be defined using 
variables in accordance with the claimed invention. As noted in the specification, a 
calculation expression can be defined based on various fields of the records in the 
database, as well as other variables, for example, the state information of the database 
(e.g., date, time, number of records, etc.) (See, for example, page 10, lines 2-6 of the 
specification). For example, a third calculation expression C3 can be expressed as: 



(Fl + F2 >= 'Constant Value C) AND (('Access Time' is 'PM') OR 
('Date of Creation' is after 1/1/2000)) 



The calculation expression C3 can also be evaluated for each of the records 
(Ri . . .R n ) individually in order to determine whether the sum of data stored in the first 
and second fields (F 1 and F2) are greater or equal to the 'Constant Value K' and 
whether either the record is accessed in the 'PM' time or the 'date of creation' of the 
record is after January 1, 2000. The 'access time' and the 'date of creation' can, for 
example, represent the state variables of a database. 

5.2. Independent Claim 38 

Independent claim 38 pertains to a computer readable medium. However, 
claim 38 recites similar features as those recited in claim 1 1 summarized above. 



CLARP027/P2616 



Page 8 



App No. 09/771,143 



6. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Ground I: Claims 11-15 and 38-42 are rejected under 35 U.S.C. § 103(a) as 
allegedly being unpatentable over Bapat et al. (U.S. Patent No. 6,236,996 Bl) in view 
of Elmasri et al. (Fundamentals of Database System). 

Ground II: Claims 11-15 and 38-42 are rejected under 35 U.S.C. § 101 for 
allegedly reciting non- statutory subject matter. 

Ground III: Claims 1 1 and 38 are rejected under 35 U.S.C. § 1 12, second 
paragraph, as allegedly being indefinite for failing to particularly point out and 
distinctly claim the subject matter which applicant regards as the invention. 

Ground IV: Claims 1 1 and 38 are rejected under 35 U.S.C. § 1 12, first 
paragraph, for allegedly failing to comply with the written description requirement. 

7. ARGUMENT 

7.1. Ground I: Claims 11-15 and 38-42 rejected under 35 U.S.C. § 103(a) 
as being allegedly unpatentable over Bapat et al. (U.S. Patent No. 
6,236,996 Bl) in view of Elmasri et al. (Fundamentals of Database 
System). 

7.1.1. Bapat et al. does NOT teach or suggest defining a calculation 
expression as a variable expression defined based on a field of 
data used in records stored in a database, wherein the 
calculation expression can be evaluated based on the field of 
data, thereby allowing access to each individual record of the 
database to be selectively controlled based on a value of a field 
of data stored for each of the records of the database (Claims 
11 and 38) 

The Examiner's rejection of claims 1 1-15 and 38-42 under § 103(a) is 
primarily based on a Granted Permission Table shown in Figure 15A of Bapat et al. 
which is reproduced below. 
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Granted Permissions Table for Table 1 



1502 



1510 



User Name 


Object Name 


Operation Type 


user_x 


ODjeci xyz 


QPI POT 


1 ICQI* V 
UOCI A 


(JUjCOL L] lo 


1 ipnATF 


user_y 


object_xyz 


SELECT 


user_y 


object_abc 


DELETE 


user_z 


object_def 


SELECT 


group_a 


object_hij 


SELECT 


group_z 


objectjkl 


SELECT 



More particularly, in the Final Office Action, the Examiner has asserted that 
"each row of the Granted Permissions Table is defined by a meaningful combination 
of variable characters or variable expression" (Final Office Action, page 13). 

Initially, it is respectfully submitted that the Granted Permissions Table of 
Bapat et al. pertains to objects. An object is well known as a fundamental concept of 
object oriented computing and clearly distinguishable from a record stored in a 
database. 

Notwithstanding this distinction, contrary to the Examiner's assertion, it is 
respectfully submitted that each row of the Granted Permissions Table of Bapat et al. 
is not a variable expression. It is apparent that each item in each row has a 
predetermined or fixed value. For example, row 1 specifies the known and 
determined values of a user, object and an operation type, namely, user x, 
object_xyz, and SELECT. As such, it is respectfully submitted that no row of the 
Granted Permissions Table of Bapat et al. can possibly be considered to be a 
calculation expression defined based on variable data. 

Furthermore, it is respectfully submitted that no row of the Granted 
Permissions Table of Bapat et al. defines an expression based on a field of data used 
in multiple records stored in a database. Notwithstanding the fact that Bapat et al. 
pertains to objects and not records of a database, it is apparent that each row of the 
Granted Permissions Table of Bapat et al. explicitly specifies access to an object 
regardless of the actual data stored in the object. In other words, permission to access 
an object can be determined solely based on what is described in the Granted 
Permissions Table of Bapat et al. Thus, access to an object can be granted 
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independent of the data stored by the object. In contrast, the claimed invention recites 
a variable expression that is defined based on a field of data used in a plurality of 
records, and therefore determining whether to grant access to a particular record is 
dependent on the actual data stored in that field for that particular record. 

Still further, it is respectfully submitted that no row of the Granted 
Permissions Table of Bapat et al. can be used to selectively control access to multiple 
records. Again, notwithstanding the fact that Bapat et al. does not pertain to records 
of a database and assuming purely for the sake of argument that each row of the 
Permissions Table of Bapat et al. somehow defines a "meaningful combination of 
variable characters or variable expression" pursuant to the Examiner's assertion, it is 
apparent the no single row of the Permissions Table of Bapat et al. can be evaluated 
for multiple objects. In other words, even assuming that each row of the Permissions 
Table of Bapat et al is some kind of an expression, it is apparent that this type of 
expression cannot be evaluated multiple times in order to determine access to 
multiple entities of a database, regardless of whether these entities are objects in a 
distributed environment or records stored in a database. 

It should be noted that the Granted Permissions Table of Bapat et al. taken as 
a whole does not teach a calculation expression as a variable expression defined 
based on a variable field of data used in multiple records stored in a database. Bapat 
et al. teaches a Granted Permissions Table with fixed terms. It is respectfully 
submitted that those skilled in the art readily appreciate the distinction between a 
table of fixed terms and a variable expression defined based on one or more variables. 
In addition, the Granted Permissions Table of Bapat et al. does not define a variable 
expression defined based on a variable field of data used in records stored in a 
database . Rather, the Granted Permissions Table of Bapat et al. is an external table 
that explicitly specifies access rights of individual users to individual objects. 

Accordingly, it is respectfully submitted that the Permissions Table of Bapat 
et al. does not define a variable expression that can be evaluated based on a field of 
data stored in multiple records (or even objects). Clearly, the methodology of Bapat 
et al. teaches searching a table of fixed terms for a particular entry in order to control 
access to an object. It is respectfully submitted that there is a clear distinction 
between searching a table of fixed terms and evaluating a variable expression. As 
such, it is respectfully submitted that the Granted Permissions Table of Bapat et al. 
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does not teach or even remotely suggest defining a variable expression that can be 
evaluated to define access for multiple records (or even objects). In fact, Bapat et al. 
teaches away from defining a single expression that can be evaluated to define access 
for multiple records as it teaches providing both a Granted Permission Table (Figure 
15 A) and a Denied Permissions Table (Figure 15B) in order to provide a 
comprehensive approach to the general problem of controlling access to objects. 

Those skilled in the art readily appreciate the advantages that a calculation 
expression provides over a conventional table that explicitly specifies the permissions 
(or denials) as fixed terms. One advantage is that there is no need to construct a table 
that explicitly states multiple possibilities. Also, there is no need to search one or 
more tables for an entry. This means that less storage and/or effort may be needed 
since a calculation expression can be evaluated only when needed (e.g., dynamically 
at runtime) to determine whether access to a record should be granted. Furthermore, 
a calculation expression provides an extremely powerful tool that can be used to 
define extremely complex expressions that could not easily be provided statically in a 
table of fixed terms. By way of example, a calculation expression can be defined 
based on a state variable of a database (e.g., current time, last time accessed, last 
person accessed) (see, for example, claim 14). 

As such, one of skilled in the art will readily realize the claimed invention is a 
clear departure from the teaching of Bapat et al. where instead of implementing tables 
that explicitly specify access rights as fixed terms, a variable expression can be 
defined and evaluated when needed in order to determine access rights. 

Accordingly, it is respectfully submitted that the Examiner's rejection is 
improper because Bapat et al. does not teach defining a calculation expression as a 
variable expression defined based on a field of data used in multiple records stored in 
a database, wherein the calculation expression can be evaluated based on the field of 
data, thereby allowing access to each individual record of the database to be 
selectively controlled based on a value of a field of data stored for each of the records 
of the database. 

Moreover, it is respectfully submitted that the cited art does not teach or even 
remotely suggest these features. Accordingly, it is respectfully submitted that 
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independent claims 11,38 and their dependent claims are patentable over the cited art 
for at least these reasons. 

7.1.2. Bapat et al. does NOT teach or suggest defining a calculation 
expression that can be evaluated based on a state variable of a 
database (claim 14) 

It should be noted that the dependent claims recite additional features that 
render them patentable over the cited art for additional reasons. For example, claim 
14 additionally recites: 

"wherein said calculation expression can be evaluated at least partly based 
on at least one state variable of said database, wherein said state variable can indicate 
the condition of an element of said database at a particular time." 

It is noted that Bapat et al. states that " a special operation type value, such as 
a database NULL value, can be used to represent "all operation types" which would 
give global grant (Col. 26, lines 55-63). However, it is respectfully submitted that 
representing all objects or operations with a special value such as NULL does not 
teach or suggest a calculation expression that can be evaluated based on a state 
variable of a database . In fact, such global representation requires no evaluation for 
individual records (or even objects) as by definition it provides or denies access to all 
of them. 

7. 1.3. Bapat et al. does NOT teach or suggest evaluating a 
calculation expression for a plurality of records based on a 
field of data stored for each record (claim 11 and 38) 

In the Final Office Action, the Examiner has asserted that checking the 
Granted Permissions Table of Bapat et al. "to see if user has specific granted items" 
teaches evaluating a calculation expression based on a field of data stored for multiple 
records (Final Office Action, page 13). Initially, it is respectfully submitted that this 
assertion contradicts the Examiner's earlier assertion that each row of the Granted 
Permissions Table of Bapat et al. is a calculation expression. If a row of the Granted 
Permissions Table of Bapat et al. can be considered to be a calculation expression, 
the Examiner needs to show that Bapat et al. teaches evaluating the row for multiple 
records (or at least multiple objects). Furthermore, checking a permission table to 
determine whether an entry exists (or does not exist) for a particular record is not the 
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same as evaluating a calculation expression multiple times. Still further, searching a 
table to find an entry does not teach evaluating a variable expression based on data 
stored in a particular field of a record in order to determine whether to grant access to 
that particular record. Again, it should be noted that Bapat et al. teaches using both a 
Granted Permissions Table and a Denied Permissions Table (Figures 15A and 15B). 
Hence, the methodology of Bapat et al. teaches away from evaluating a single 
calculation expression in order to control access to multiple records stored in a 
database as it teaches searching not just one but multiple tables in order to control 
access to objects. 

7. 1.4. Bapat et al. does NOT teach or suggest determining at least 
one value for a field of data stored in a record and using it to 
evaluate a variable expression in order to control access to 
that record (claims 11 and 38) 

Contrary to the Examiner's assertion, it is respectfully submitted that checking 
a "grant" table to see if a user has specific "granted items" does not teach these 
features. It is respectfully submitted that Bapat et al. does not teach or suggest 
determining a value for a field of data in a particular record and using it to evaluate a 
variable expression to control access to the record. Instead, access is controlled 
externally with respect to the data stored in the objects by means of permission and 
deny tables that specifically state whether access to an object is granted or denied. 

7.1.5. The Examiner has failed to establish a prima facie case of 
obviousness because the Examiner has failed to address the 
claimed feature of: "defining a calculation expression for a 
password" (claims 11 and 38) 

Claim 1 1 recites defining a calculation expression for an identified password 
associated with one or more users of a database. In the Final Office Action, the 
Examiner has admitted that Bapat et al. does not teach this claimed feature (Final 
Office Action, page 15). In order to cure this deficiency, the Examiner needs to at 
least show that defining a calculation expression for a password is taught. Instead, 
the Examiner has merely asserted that Elmasri teaches " a method for protecting 
access to a database system by identifying a password that is associated with one or 
more users of said database" (Final Office Action, page 15). It is respectfully 
submitted that the mere assertion that a password can be associated with one or more 
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users does not even address the claimed feature o f defining a calculation expression 
for a password . As such, the Examiner has failed to address all of the claimed 
features and consequently has failed to establish a prima facie case of obviousness. 

7.1.6. The cited art does not teach or suggest defining a calculation 
expression for a password (claims 11 and 38) 

Moreover, it is respectfully submitted that the cited art does not teach or 
suggest defining a calculation expression for a password . Accordingly, it is 
respectfully submitted that the claimed invention is patentable over the cited art for 
this additional reason. 

7.1. 7. The Examiner has failed to establish a prima facie case of 
obviousness because the Examiner has failed to provide a 
motivation or suggestion for defining a calculation expression 
for a password (claims 11 and 38) 

In the Final Office Action, the Examiner has asserted that "by using a 
password to identify a user as taught by Elmasri, the database system is secured and 
data is protected from misuse and against intruders" (Final Office Action, page 15). 

It is respectfully submitted that the mere assertion that the references can be 
combined or modified and/or the claimed invention is within the capabilities of one of 
ordinary skilled in the art, is not sufficient to establish a prima facie case of 
obviousness (MPEP 2143.01, paragraphs III. and IV). Clearly, the mere assertion 
that a proposed combination would result in a beneficial result (i.e., a secure system) 
is not enough to establish a prima facie case of obviousness. In this case, the 
Examiner needs to at least provide a motivation or suggestion for defining a 
calculation expression for a password in the first place so that any beneficial result 
can be realized. 

7.2. Ground II: Claims 11-15 and 38-42 rejected under 35 U.S.C. § 101 

In the Final Office Action, the Examiner has asserted that claims 1 1 and 38 do 
not produce a tangible and useful result. Contrary to the Examiner's assertion, it is 
respectfully submitted that the recited feature of determining a result that effectively 
indicates whether to grant one or more users access to a record stored in a database is 
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a concrete, tangible and useful result as it allows selectively controlling access to 
records stored in the database. 

Accordingly, it is respectfully submitted that the Examiner's under 35 U.S.C. 
§ 101 is improper and should be withdrawn. 

7.3. Ground III: Claims 1 1 and 38 rejected under 35 U.S.C. § 1 12, first 
paragraph 

In the Final Office Action, the Examiner has asserted that the specification is 
not described in such a way to reasonably convey to one skilled in the art how to use 
at least one value as input to a calculation expression in order to evaluate a 
calculation expression for a record. 

With reference to Figure 7 of the present application, the specification states 
that the exemplary calculation expression 664 specifies that the field "billing state" is 
equal to "CA" (California) (Specification, page 14). Further, with reference to Figure 
8, the specification states that: 

"an exemplary file ACCOUNTS that includes records "ACC001," "ACC002," 
"ACC003," and "ACC004" is displayed in a window 800." The specification further 
states that the calculation expression 604 of Figure 7 (Billing state = "CA") can be used 
to control access to a record. More particularly, the specification states: "Recalling the 
exemplary calculation expression 604 of Figure 7, given this expression, access to a 
record with respect to an operation would be granted only when the field "State" 
(Billing State) of that record is equal to "CA". Accordingly, using the calculation 
expression 604, access to records shown in Figure 8 with respect to editing privileges, 
for example, would be limited to editing records "ACC001", "ACC002", and 
"ACC004". Thus, the user will not be granted editing privileges to record "ACC003" 
since the field "State" of this record is not equal to "CA". In this way, a calculation 
expression can be evaluated with respect to a record to determine whether to grant or 
deny access to each record" (Specification, page 14). 

It is respectfully submitted that the specification makes it abundantly clear to 
one of ordinary skill in the art at the time of the invention that evaluating a calculation 
expression can comprise determining the actual value for a field of data stored for a 
particular record in a database and effectively using the actual value as input (or an 
input parameter) with respect to the calculation expression in order to evaluate the 
calculation expression. With reference to Figure 8, the specification clearly conveys 
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that the actual value of a field of a particular record can, for example, be the actual 
value of the field "State" in the record "ACC003" (Shown on Figure 8). This actual 
value happens to be "NY" which is not equal to the value "CA" used in the 
calculation expression, thereby resulting in denial of access for that particular record 
(record identified by "ACC003") when the calculation expression is evaluated. 

Furthermore, it is respectfully submitted that one of ordinary skill in the art 
would readily know that evaluating a calculation expression that is defined based on a 
field of data requires determining the actual value of data stored in the corresponding 
field of a particular record in order to evaluate the calculation expression for the 
particular record. It is also abundantly clear that the actual value of the field has to be 
used as input to the calculation expression in order to evaluate the calculation 
expression (i.e., the actual value would be substituted in place of the variable field in 
the same way as an actual value (e.g., 10) for a variable X can be input to an 



expression f'if X < 5 then ..."| in order to evaluate the expression). 



Finally, the Board's attention is respectfully directed to the Microsoft 
Computer Dictionary, Fifth Edition, which defines a field as "a location in a record in 
which a particular type of data is stored." Accordingly, it is respectfully submitted 
that one of ordinary skill in the art would readily know that evaluating a calculation 
expression that is defined based on a field of data requires determining the actual 
value stored for that field and using the value as input to the calculation expression in 
order to evaluate the calculation expression to obtain a result (or output) for the 
calculation expression (e.g., determining a true of false value for the result). 

Accordingly, it is respectfully submitted that the Examiner's under 35 U.S.C. 
§ 1 1 2, first paragraph is improper and should be withdrawn. 

7.4. Ground IV: Claims 1 1 and 38 are rejected under 35 U.S.C. § 1 12, 
second paragraph 

In the Final Office Action, the Examiner has asserted that claims 1 1 and 38 
omit an essential step because only the first record of a plurality of records is 
evaluated. Claims 11 and 38 recite: 

"evaluating said calculation expression for each of said plurality of 

records." 
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Hence, contrary to the Examiner's assertion, it is respectfully submitted that 
the claims 1 1 and 38 do NOT omit an essential step as the calculation expression is 
evaluated for multiple records in order to control access to multiple records. 

Claims 1 1 and 38 further clarify that evaluating the expression for a particular 
record (first record) comprises the additional operations of: (a) determining at least 
one value, (b) using the at least one value, and (c) determining a first result. It is 
respectfully submitted that it is not essential that these steps be recited for a second 
record. As noted above, it is respectfully submitted that one of ordinary skill in the 
art would readily know that evaluating a calculation expression that is defined based 
on a field of data requires determining the actual value stored for that field and using 
the value as input to the calculation expression in order to evaluate the calculation 
expression to obtain a result (or output) for the calculation expression (e.g., 
determining a true of false value for the result). 

Accordingly, it is respectfully requested that the Examiner's rejection under 
section 35 U.S.C. § 1 12, second paragraph is improper and should be withdrawn. 
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8. CONCLUSION 

In view of the foregoing, it is respectfully submitted that the Examiner's 
rejection of claim 1 1-15 and 38-42 is erroneous. Accordingly, the rejection of claims 
11-15 and 38-42 should be reversed. 

Respectfully submitted, 



BEYER, WEAVER LLP 
Attorneys for Appellant 



/RMahboubian/ 
Ramin Mahboubian 
Registration No. 44,890 
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9. CLAIMS APPENDIX 

CLAIMS ON APPEAL 

1-10. (Canceled) 

1 1 . (Previously Presented) A method of controlling access to records stored in a 
database, said method comprising: 

identifying a password that is associated with one or more users of said 
database; 

defining a calculation expression for said identified password, wherein said 
calculation expression is a variable expression defined based on at least one field of 
data used in a plurality of records stored in said database, wherein said calculation 
expression can be evaluated at least partly based on said at least one field of data used 
in said plurality of records, wherein said at least one field of data is a variable which 
may have different values for each of said plurality of records, thereby allowing 
access to each individual record of said plurality of records to be selectively 
controlled based on at least one value of said at least one field of data stored for each 
of said plurality of records of said database, and wherein said calculation expression 
defines access privileges of said one or more users with respect to at least one 
operation that may be requested to be performed by said one or more users on said 
plurality of records of said database; 

receiving a request to perform said at least one operation on said plurality of 
records of said database, said request being identified as a request made by said one 
or more users associated with said password; and 

evaluating said calculation expression for each of said plurality of records, 
based on said at least one field of data, when said request has been received, wherein 
said evaluating comprises: (a) determining at least one value for said at least one field 
of data stored for a first record of said plurality of records, (b) using said at least one 
value as input to said calculation expression to evaluate said calculation expression 
for said first record, and (c) determining a first result for said calculation expression 
based on said evaluation of said calculation expression for said first record, wherein 
said first result effectively indicates whether to grant access to said first record. 
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12. (Original) A method as recited in claim 11, wherein said at least one 
operation can be a browse, an edit, or a delete operation. 

13. (Original) A method as recited in claim 11, wherein said calculation 
expression is not explicitly defined for said at least one operation but said calculation 
expression is one that has been defined for another operation which has been 
considered as a related operation to said at least one operation. 

14. (Previously Presented) A method as recited in claim 11, 

wherein said calculation expression can be evaluated at least partly based on 
at least one state variable of said database, wherein said state variable can indicate the 
condition of an element of said database at a particular time. 

15. (Original) A method as recited in claim 14, wherein said method further 
comprises: 

granting temporary or limited access to said at least one record to allow said 
evaluating of said calculation expression. 

16-37. (Canceled) 

38. (Previously Presented) A computer readable medium including computer 
program code for controlling access to records stored in a database, said computer 
readable medium comprising: 

computer program code for identifying a password that is associated with one 
or more users of said database; 

computer program code for defining a calculation expression for said 
identified password, wherein said calculation expression is a variable expression 
defined based on at least one field of data used in a plurality of records stored in said 
database, wherein said calculation expression can be evaluated at least partly based 
on said at least one field of data used in said plurality of records, wherein said at least 
one field of data is a variable which may have different values for each of said 
plurality of records, thereby allowing access to each individual record of said 
plurality of records to be selectively controlled based on at least one value of said at 
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least one field of data stored for each of said plurality of records of said database, and 
wherein said calculation expression defines access privileges of said one or more 
users with respect to at least one operation that may be requested to be performed by 
said one or more users on said plurality of records of said database; 

computer program code for receiving a request to perform said at least one 
operation on said plurality of records of said database, said request being identified as 
a request made by said one or more users associated with said password; and 

computer program code for evaluating said calculation expression for each of 
said plurality of records, based on at least one field of data, when said request has 
been received, wherein said evaluating comprises: (a) determining at least one value 
for said at least one field of data stored for a first record of said plurality of records, 
(b) using said at least one value as input to said calculation expression to evaluate 
said calculation expression for said first record, and (c) determining a first result for 
said calculation expression based on said evaluation of said calculation expression for 
said first record, wherein said first result effectively indicates whether to grant access 
to said first record. 

39. (Previously Presented) A computer readable medium as recited in claim 38, 
wherein said at least one operation can be a browse, an edit, or a delete operation. 

40. (Previously Presented) A computer readable medium as recited in claim 38, 
wherein said calculation expression is not explicitly defined for said at least one 
operation but said calculation expression is one that has been defined for another 
operation which has been considered as a related operation to said at least one 
operation. 

41 . (Previously Presented) A computer readable medium as recited in claim 38, 
wherein said calculation expression can be evaluated at least partly based on at least 
one state variable of said database. 

42. (Previously Presented) A computer readable medium as recited in claim 38, 
further comprising: 

computer program code for granting temporary or limited access to said at 
least one record to allow said evaluating of said calculation expression. 
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43-58. (Canceled) 
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10. EVIDENCE APPENDIX 

No evidence has been submitted pursuant to§§ 1.130, 1.131, or 1.1 32 of 37 
CFR, nor has any other evidence been entered by the examiner. 
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1 1 . RELATED PROCEEDINGS APPENDIX 

There have been no decisions rendered by a court or the Board in any 
proceeding identified pursuant to paragraph (c)(l)(ii) of 37 CFR 41.37(c)(1). 
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